En-têtes de sécurité frontend : Maîtriser la Content Security Policy (CSP)

Dans le paysage numérique actuel, où les applications web sont de plus en plus complexes et interconnectées, la protection contre les menaces de sécurité est primordiale. Alors que la sécurité backend reçoit souvent une attention particulière, la sécurité frontend est tout aussi cruciale. Les en-têtes de sécurité frontend agissent comme la première ligne de défense, fournissant un mécanisme pour instruire le navigateur sur la manière de se comporter et de protéger les utilisateurs contre diverses attaques. Parmi ces en-têtes, la Content Security Policy (CSP) se distingue comme un outil puissant pour atténuer un large éventail de risques.

Que sont les en-têtes de sécurité frontend ?

Les en-têtes de sécurité frontend sont des en-têtes de réponse HTTP qu'un serveur web envoie au navigateur. Ces en-têtes contiennent des instructions sur la manière dont le navigateur doit gérer le contenu qu'il reçoit. Ils aident à prévenir des attaques courantes telles que :

• Cross-Site Scripting (XSS) : Injection de scripts malveillants dans des sites web de confiance.
• Clickjacking : Tromper les utilisateurs pour qu'ils cliquent sur quelque chose de différent de ce qu'ils perçoivent.
• Attaques de l'homme du milieu (Man-in-the-Middle) : Interception de la communication entre l'utilisateur et le serveur.

Certains des en-têtes de sécurité frontend les plus importants incluent :

• Content Security Policy (CSP) : Définit les sources à partir desquelles le navigateur est autorisé à charger des ressources.
• Strict-Transport-Security (HSTS) : Force le navigateur à utiliser HTTPS pour toutes les communications avec le site web.
• X-Frame-Options : Empêche le site web d'être intégré dans une iframe, atténuant ainsi les attaques de type clickjacking.
• X-XSS-Protection : Active le filtre XSS intégré du navigateur. (Note : Souvent remplacé par la CSP mais peut toujours fournir une couche de défense).
• Referrer-Policy : Contrôle la quantité d'informations de référent envoyées avec les requêtes.
• Feature-Policy (maintenant Permissions-Policy) : Permet aux développeurs d'activer et de désactiver sélectivement les fonctionnalités et les API du navigateur.

Plongée en profondeur dans la Content Security Policy (CSP)

La Content Security Policy (CSP) est un en-tête de réponse HTTP qui contrôle les ressources que l'agent utilisateur est autorisé à charger pour une page donnée. Elle établit essentiellement une liste blanche des sources de contenu approuvé, réduisant considérablement le risque d'attaques XSS. En définissant explicitement les origines à partir desquelles des ressources telles que les scripts, les feuilles de style, les images et les polices peuvent être chargées, la CSP rend beaucoup plus difficile pour les attaquants d'injecter du code malveillant dans votre site web.

Comment fonctionne la CSP

La CSP fonctionne en fournissant au navigateur une liste de sources approuvées pour différents types de contenu. Lorsque le navigateur rencontre une ressource qui viole la CSP, il bloque la ressource et signale la violation. Ce mécanisme de blocage empêche l'exécution de code malveillant, même si un attaquant parvient à l'injecter dans le HTML.

Directives CSP

Les directives CSP sont les composants principaux d'une politique CSP. Elles spécifient les sources autorisées pour différents types de ressources. Certaines des directives les plus couramment utilisées incluent :

• default-src : Définit la source par défaut pour tous les types de ressources. C'est une directive de repli qui s'applique lorsque d'autres directives plus spécifiques ne sont pas définies.
• script-src : Spécifie les sources autorisées pour le JavaScript.
• style-src : Spécifie les sources autorisées pour les feuilles de style CSS.
• img-src : Spécifie les sources autorisées pour les images.
• font-src : Spécifie les sources autorisées pour les polices.
• media-src : Spécifie les sources autorisées pour l'audio et la vidéo.
• object-src : Spécifie les sources autorisées pour les plugins comme Flash. (Il est généralement préférable d'éviter d'autoriser les plugins si possible).
• frame-src : Spécifie les sources autorisées pour les cadres (iframes).
• connect-src : Spécifie les sources autorisées pour les requêtes réseau (AJAX, WebSockets).
• base-uri : Restreint les URL qui peuvent être utilisées dans un élément <base>.
• form-action : Restreint les URL vers lesquelles les formulaires peuvent être soumis.
• frame-ancestors : Spécifie les parents valides qui peuvent intégrer une page en utilisant <frame>, <iframe>, <object>, <embed>, ou <applet>. Cette directive offre une protection contre le Clickjacking.
• upgrade-insecure-requests : Ordonne aux agents utilisateurs de traiter toutes les URL non sécurisées d'un site (chargées via HTTP) comme si elles avaient été remplacées par des URL sécurisées (chargées via HTTPS). Cette directive est destinée aux sites web en cours de migration de HTTP vers HTTPS.
• report-uri : Spécifie une URL à laquelle le navigateur doit envoyer des rapports sur les violations de la CSP. Obsolète au profit de `report-to`.
• report-to : Spécifie un nom de groupe défini dans un en-tête `Report-To`. Cela permet un contrôle plus fin des rapports, y compris la spécification de plusieurs points de terminaison pour les rapports.

Valeurs de source CSP

Les valeurs de source définissent les origines à partir desquelles les ressources sont autorisées à être chargées. Certaines valeurs de source courantes incluent :

• * : Autorise le contenu de n'importe quelle source (À éviter en production !).
• 'self' : Autorise le contenu de la même origine (schéma, hôte et port) que le document protégé.
• 'none' : N'autorise le contenu d'aucune source.
• 'unsafe-inline' : Autorise l'utilisation de JavaScript et de CSS en ligne (À éviter en production !).
• 'unsafe-eval' : Autorise l'utilisation de l'évaluation de code dynamique (par ex., eval(), Function()) (À éviter en production !).
• 'strict-dynamic' : Spécifie que la confiance explicitement accordée à un script présent dans le balisage, en l'accompagnant d'un nonce ou d'un hash, doit être propagée à tous les scripts chargés par cet ancêtre.
• 'unsafe-hashes' : Autorise des gestionnaires d'événements en ligne spécifiques. Ceci est généralement déconseillé en raison de sa complexité et de son avantage limité.
• data: : Permet de charger des ressources à partir d'URL de données (par ex., des images intégrées). À utiliser avec prudence.
• mediastream: : Permet d'utiliser les URI `mediastream:` comme source multimédia.
• blob: : Permet d'utiliser les URI `blob:` comme source multimédia.
• filesystem: : Permet de charger des ressources à partir d'un système de fichiers.
• https://example.com : Autorise le contenu d'un domaine et d'un port spécifiques.
• *.example.com : Autorise le contenu de n'importe quel sous-domaine de example.com.
• nonce-{valeur-aléatoire} : Autorise les scripts ou les styles avec un attribut nonce correspondant. Cela nécessite la génération côté serveur d'une valeur de nonce aléatoire pour chaque requête.
• sha256-{valeur-hash} : Autorise les scripts ou les styles avec un hash SHA256, SHA384 ou SHA512 correspondant.

Modes CSP : Application (Enforce) vs. Rapport uniquement (Report-Only)

La CSP peut être déployée dans deux modes :

• Mode d'application (Enforce) : Dans ce mode, le navigateur bloque toutes les ressources qui violent la CSP. C'est le mode recommandé pour les environnements de production. La CSP est envoyée via l'en-tête `Content-Security-Policy`.
• Mode rapport uniquement (Report-Only) : Dans ce mode, le navigateur signale les violations de la CSP mais ne bloque pas les ressources. C'est utile pour tester et évaluer une CSP avant de l'appliquer. La CSP est envoyée via l'en-tête `Content-Security-Policy-Report-Only`.

Mise en œuvre de la CSP : Un guide étape par étape

La mise en œuvre de la CSP peut sembler intimidante, mais en suivant une approche structurée, vous pouvez sécuriser efficacement votre application web.

1. Commencer avec une politique en mode rapport uniquement

Commencez par déployer une CSP en mode rapport uniquement. Cela vous permet de surveiller les violations sans perturber la fonctionnalité de votre site web. Configurez la directive report-uri ou report-to pour envoyer les rapports de violation à un point de terminaison désigné.

Exemple d'en-tête (Rapport uniquement) : Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

2. Analyser les rapports de violation

Analysez attentivement les rapports de violation pour identifier quelles ressources sont bloquées et pourquoi. Cela vous aidera à comprendre les dépendances des ressources de votre site web et à identifier les vulnérabilités de sécurité potentielles.

Les rapports de violation sont généralement envoyés sous forme de charges utiles JSON au point de terminaison report-uri ou report-to configuré. Ces rapports contiennent des informations sur la violation, telles que l'URI bloquée, la directive violée et l'URI du document.

3. Affiner la politique CSP

En vous basant sur les rapports de violation, affinez votre politique CSP pour autoriser les ressources légitimes tout en maintenant une posture de sécurité solide. Ajoutez des valeurs de source spécifiques pour les ressources qui sont bloquées. Envisagez d'utiliser des nonces ou des hashes pour les scripts et styles en ligne afin d'éviter d'utiliser 'unsafe-inline'.

4. Passer en mode d'application (Enforce)

Une fois que vous êtes sûr que votre politique CSP ne bloque pas les ressources légitimes, passez en mode d'application. Cela bloquera toutes les violations restantes et fournira une couche de sécurité robuste contre les attaques XSS.

Exemple d'en-tête (Application) : Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

5. Surveiller et maintenir la politique CSP

La CSP n'est pas une solution à configurer une seule fois. Il est essentiel de surveiller en permanence votre politique CSP et de la mettre à jour à mesure que votre site web évolue et que de nouvelles menaces de sécurité apparaissent. Examinez régulièrement les rapports de violation et ajustez la politique si nécessaire.

Exemples pratiques de CSP

Voyons quelques exemples pratiques de CSP pour différents scénarios :

Exemple 1 : CSP de base pour un site web simple

Cette CSP autorise le contenu de la même origine et les images de n'importe quelle source.

Content-Security-Policy: default-src 'self'; img-src *

Exemple 2 : CSP avec des sources de script et de style spécifiques

Cette CSP autorise les scripts de la même origine et d'un CDN spécifique, et les styles de la même origine ainsi que les styles en ligne.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'

Exemple 3 : CSP avec des nonces pour les scripts en ligne

Cette CSP requiert un nonce unique pour chaque script en ligne.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0mn0nc3'

HTML :

<script nonce="r4nd0mn0nc3">console.log('Bonjour, le monde !');</script>

Important : La valeur du nonce doit être générée dynamiquement sur le serveur pour chaque requête. Cela empêche les attaquants de réutiliser le nonce.

Exemple 4 : CSP restreignant les ancêtres de cadre pour prévenir le Clickjacking

Cette CSP empêche la page d'être intégrée dans une iframe sur n'importe quel domaine sauf `https://example.com`.

Content-Security-Policy: frame-ancestors 'self' https://example.com

Exemple 5 : Une CSP plus restrictive utilisant 'strict-dynamic' et un repli sur 'self'

Cette CSP exploite `strict-dynamic` pour les navigateurs modernes tout en prenant en charge les anciens navigateurs qui ne le supportent pas. Elle inclut également un `report-uri` pour surveiller les violations.

Content-Security-Policy: default-src 'self'; script-src 'strict-dynamic' 'nonce-{random-nonce}' 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

N'oubliez pas de remplacer `{random-nonce}` par une valeur de nonce générée dynamiquement côté serveur.

CSP et applications monopages (SPA)

La mise en œuvre de la CSP dans les SPA peut être difficile en raison de la nature dynamique de ces applications. Les SPA dépendent souvent fortement du JavaScript pour générer et manipuler le DOM, ce qui peut entraîner des violations de la CSP si ce n'est pas géré avec soin.

Voici quelques conseils pour mettre en œuvre la CSP dans les SPA :

• Évitez 'unsafe-inline' et 'unsafe-eval' : Ces directives doivent être évitées autant que possible dans les SPA. Elles affaiblissent considérablement la sécurité de votre application.
• Utilisez des Nonces ou des Hashes : Utilisez des nonces ou des hashes pour les scripts et les styles en ligne. C'est l'approche recommandée pour les SPA.
• Envisagez les Trusted Types : Trusted Types est une API de navigateur qui aide à prévenir les vulnérabilités XSS basées sur le DOM. Elle peut être utilisée en conjonction avec la CSP pour renforcer davantage la sécurité.
• Utilisez un framework compatible avec la CSP : Certains frameworks frontend (comme React avec des configurations spécifiques, Angular et Vue.js) offrent des fonctionnalités pour vous aider à mettre en œuvre la CSP plus facilement.

Autres en-têtes de sécurité frontend importants

Bien que la CSP soit une pierre angulaire de la sécurité frontend, d'autres en-têtes jouent un rôle crucial dans la fourniture d'une stratégie de défense complète :

Strict-Transport-Security (HSTS)

L'en-tête Strict-Transport-Security (HSTS) ordonne au navigateur de toujours utiliser HTTPS pour se connecter au site web. Cela prévient les attaques de l'homme du milieu qui tentent de dégrader la connexion vers HTTP.

Exemple d'en-tête : Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age : Spécifie la durée (en secondes) pendant laquelle le navigateur doit se souvenir de n'accéder au site que via HTTPS. Une valeur de 31536000 secondes (1 an) est recommandée pour les environnements de production.
• includeSubDomains : Indique que la politique HSTS s'applique à tous les sous-domaines du domaine.
• preload : Permet au domaine d'être inclus dans une liste de domaines activés pour HSTS qui est préchargée dans les navigateurs. Cela nécessite de soumettre votre domaine à la liste de préchargement HSTS maintenue par Google.

X-Frame-Options

L'en-tête X-Frame-Options prévient les attaques de type clickjacking en contrôlant si le site web peut être intégré dans une iframe.

Exemple d'en-tête : X-Frame-Options: DENY

Valeurs possibles :

• DENY : Empêche la page d'être affichée dans une iframe, quelle que soit l'origine.
• SAMEORIGIN : Permet à la page d'être affichée dans une iframe uniquement si l'origine de l'iframe correspond à l'origine de la page.
• ALLOW-FROM uri : Permet à la page d'être affichée dans une iframe uniquement si l'origine de l'iframe correspond à l'URI spécifiée. Note : Cette option est obsolète et peut ne pas être prise en charge par tous les navigateurs.

Note : La directive frame-ancestors de la CSP offre un moyen plus flexible et puissant de contrôler l'intégration dans des cadres et est généralement préférée à X-Frame-Options.

X-XSS-Protection

L'en-tête X-XSS-Protection active le filtre XSS intégré du navigateur. Bien que la CSP soit une solution plus robuste pour prévenir les attaques XSS, cet en-tête peut fournir une couche de défense supplémentaire, en particulier pour les anciens navigateurs qui ne prennent peut-être pas entièrement en charge la CSP.

Exemple d'en-tête : X-XSS-Protection: 1; mode=block

• 1 : Active le filtre XSS.
• 0 : Désactive le filtre XSS.
• mode=block : Ordonne au navigateur de bloquer la page si une attaque XSS est détectée.
• report=uri : Spécifie une URL à laquelle le navigateur doit envoyer un rapport si une attaque XSS est détectée.

Referrer-Policy

L'en-tête Referrer-Policy contrôle la quantité d'informations de référent qui est envoyée avec les requêtes. Les informations de référent peuvent être utilisées pour suivre les utilisateurs à travers les sites web, donc leur contrôle peut améliorer la confidentialité des utilisateurs.

Exemple d'en-tête : Referrer-Policy: strict-origin-when-cross-origin

Quelques valeurs courantes :

• no-referrer : Ne jamais envoyer l'en-tête Referer.
• no-referrer-when-downgrade : Ne pas envoyer l'en-tête Referer à des origines sans TLS (HTTPS).
• origin : Envoyer uniquement l'origine (schéma, hôte et port) dans l'en-tête Referer.
• origin-when-cross-origin : Envoyer l'origine pour les requêtes inter-origines et l'URL complète pour les requêtes de même origine.
• same-origin : Envoyer l'en-tête Referer pour les requêtes de même origine, mais pas pour les requêtes inter-origines.
• strict-origin : Envoyer uniquement l'origine lorsque le niveau de sécurité du protocole reste le même (HTTPS vers HTTPS), mais ne pas envoyer d'en-tête vers une destination moins sécurisée (HTTPS vers HTTP).
• strict-origin-when-cross-origin : Envoyer l'origine lors d'une requête de même origine. Pour les requêtes inter-origines, envoyer l'origine uniquement lorsque le niveau de sécurité du protocole reste le même (HTTPS vers HTTPS), mais ne pas envoyer d'en-tête vers une destination moins sécurisée (HTTPS vers HTTP).
• unsafe-url : Envoyer l'URL complète dans l'en-tête Referer, quelle que soit l'origine. À utiliser avec une extrême prudence, car cela peut exposer des informations sensibles.

Permissions-Policy (anciennement Feature-Policy)

L'en-tête Permissions-Policy (anciennement connu sous le nom de Feature-Policy) permet aux développeurs d'activer et de désactiver sélectivement les fonctionnalités et les API du navigateur. Cela peut aider à réduire la surface d'attaque de votre application et à améliorer la confidentialité des utilisateurs.

Exemple d'en-tête : Permissions-Policy: geolocation=()

Cet exemple désactive l'API de géolocalisation pour le site web.

D'autres fonctionnalités qui peuvent être contrôlées avec Permissions-Policy incluent :

• camera
• microphone
• geolocation
• accelerometer
• gyroscope
• magnetometer
• usb
• midi
• payment
• fullscreen

Configurer les en-têtes de sécurité sur différentes plateformes

La méthode pour configurer les en-têtes de sécurité varie en fonction du serveur web ou de la plateforme que vous utilisez. Voici quelques exemples courants :

Apache

Vous pouvez définir des en-têtes de sécurité dans Apache en les ajoutant au fichier .htaccess ou au fichier de configuration du serveur (httpd.conf).

Exemple de configuration .htaccess :

<IfModule mod_headers.c>
 Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report"
 Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
 Header set X-Frame-Options "DENY"
 Header set X-XSS-Protection "1; mode=block"
 Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Nginx

Vous pouvez définir des en-têtes de sécurité dans Nginx en les ajoutant au bloc server dans le fichier de configuration de Nginx (nginx.conf).

Exemple de configuration Nginx :

server {
 listen 443 ssl;
 server_name example.com;

 add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report";
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
 add_header X-Frame-Options "DENY";
 add_header X-XSS-Protection "1; mode=block";
 add_header Referrer-Policy "strict-origin-when-cross-origin";

 ...
}

Node.js (Express)

Vous pouvez définir des en-têtes de sécurité dans Node.js en utilisant un middleware comme Helmet.

Exemple avec Helmet :

const express = require('express');
const helmet = require('helmet');

const app = express();

app.use(helmet());

// Personnaliser la CSP si nécessaire
app.use(helmet.contentSecurityPolicy({
 directives: {
 defaultSrc: ["'self'"],
 scriptSrc: ["'self'", "https://cdn.example.com"],
 styleSrc: ["'self'", "'unsafe-inline'"],
 imgSrc: ["'self'", "data:"],
 reportUri: '/csp-report'
 },
}));

app.get('/', (req, res) => {
 res.send('Bonjour le monde !');
});

app.listen(3000, () => {
 console.log('Serveur à l\'écoute sur le port 3000');
});

Cloudflare

Cloudflare vous permet de définir des en-têtes de sécurité en utilisant leurs Page Rules ou Transform Rules.

Tester vos en-têtes de sécurité

Après avoir mis en place des en-têtes de sécurité, il est crucial de les tester pour s'assurer qu'ils fonctionnent correctement. Plusieurs outils en ligne peuvent vous aider à analyser les en-têtes de sécurité de votre site web :

• SecurityHeaders.com : Un outil simple et efficace pour analyser les en-têtes de sécurité.
• Observatoire Mozilla : Un outil complet pour tester la sécurité des sites web, y compris les en-têtes de sécurité.
• WebPageTest.org : Vous permet de visualiser les en-têtes HTTP dans le graphique en cascade (waterfall chart).

Conclusion

Les en-têtes de sécurité frontend, en particulier la Content Security Policy (CSP), sont essentiels pour protéger les applications web contre diverses attaques et améliorer la sécurité des utilisateurs. En mettant en œuvre et en maintenant soigneusement ces en-têtes, vous pouvez réduire considérablement le risque de XSS, de clickjacking et d'autres vulnérabilités de sécurité. N'oubliez pas de commencer par une politique en mode rapport uniquement, d'analyser les rapports de violation, d'affiner la politique, puis de passer en mode d'application. Surveillez et mettez à jour régulièrement vos en-têtes de sécurité pour maintenir la sécurité de votre site web à mesure qu'il évolue et que de nouvelles menaces apparaissent.

En adoptant une approche proactive de la sécurité frontend, vous pouvez créer des applications web plus sûres et plus fiables qui protègent vos utilisateurs et votre entreprise.